


Fonts, and colors, and work skins, oh my!

by Charles_Rockafellor



Category: css - Fandom
Genre: Background - Freeform, Backgrounds, CSS, Coding, Font color, Font size, HTML, Highlight - Freeform, Snippet, Unconventional Format, Work Skin, Work Skins, ao3 - Freeform, code, fonts, highlights, how to, tutorial, workskin, workskins
Language: English
Status: Completed
Published: 2021-01-24
Updated: 2021-01-24
Packaged: 2021-03-15 07:14:26
Rating: General Audiences
Warnings: No Archive Warnings Apply
Chapters: 1
Words: 6,798
Publisher: archiveofourown.org
Story URL: https://archiveofourown.org/works/28934610
Author URL: https://archiveofourown.org/users/Charles_Rockafellor/pseuds/Charles_Rockafellor
Summary: This explains:● how to make a work skin;● how to colorize your text and circle words and highlight backgrounds (examples in head-note), and change & resize your fonts;● the CSS code for diacritics to be rendered properly for things like “ầ” & “ồ” (so that the diacritics aren't superimposed), or “ị” (so that the underdot is directly beneath, not kerned to the left), and without breaking words such as “gầu” or “vịt” (using a monotype font for these letters would create gaps to each side of the ầ or the ị).  Head-note has corrected examples;●site skinaddenda to block / shrink tags, and block authors / works.Full code is included.This summary contains no CSS effects because although HTML tags work in summaries and are quick to type, I'm not inclined to code the CSS.  If you're interested in doing so though, then please seeHow to Override the Archive's Automated Chapter HeadersandBleed Gold.
Kudos: 9
Collections: A Guide to Coding and Fanworks, Fanfiction Reference Works, HTML & CSS stuffs, Worldbuilding Meta





	Fonts, and colors, and work skins, oh my!

**Author's Note:**

> The CSS herein will render diacritics properly (as long as the readers haven't disabled work skins, and do have at least one of the fonts named) for at least these test cases: “ầ”, “ị”, & “ồ”, without breaking words such as “gầu” or “vịt”.
> 
> It also shows how to make red, green, and blue text (or even highlight it), and you can easily do other colors, along with a few other things. Changing font size is also covered, complete with code, but not demonstrated.
> 
> Unlike the summary, this header-note **1** _does_ contain CSS effects (obviously); if you don't see any colored text or highlighted words here, then you might want to scroll to the top and hit the button in the top right corner that says “[Show Creator's Style](https://archiveofourown.org/works/28934610?style=creator)”.
> 
> This _doesn't_ teach you basic HTML (though [footnote 3](https://archiveofourown.org/works/28934610#3) explains and shows the shortest possible syntax for AO3 links), or how to use tags. I thought about writing up something on HTML as well, but chose to run a search instead and found [a good one by MohnblumenKind](https://archiveofourown.org/works/15685086/chapters/36443283) to direct you to for that.
> 
> Bonus: I know how hard it can be to find good [real-world] research information sometimes, so if you're a physics geek (or just sometimes curious), then you might enjoy “[An illustrated periodic table of hadrons](https://archiveofourown.org/works/29512119)” - pretty much self-explanatory.
> 
>   
> 
> 
> * * *

  
**Contents:**  
[Preamble]  
The code  
Make your skin  
Font size: %, em, px  
Using CSS in your HTML  
CSS to circle words  
Advanced stuff  
**Block tags**  


  


**Preamble**

My only reason for coding in AO3 is to enable a slightly more than basic typing (e.g.: alignment, typographical emphasis [bold, italic, etc.]), so that I can [judiciously] apply different fonts or colors. I'm a book reader (i.e.: dead trees), and although I value the capabilities of webpages' layouts and such, my writing presentation is aimed at simpler things -- but fonts or colors aren't immediately available by GUI nor even inline HTML (for some very good reasons, I'd say). Nevertheless, the course of events brought me to the question of [CSS] work skins to perform these functions, and then on to the thought of applying them to the Summary section solely to demonstrate these same effects, at which point I noticed that although one can certainly cause them there, those effects (except for the choice of font, oddly enough) _**notably** don't_ appear when viewing the same summary as listed in the search results page (and so I saw no impetus -- for _my_ purposes -- to add the CSS code for higher level effects, if they'd be seen only when in the fic itself, where you'd be able to see them in the header Notes through straight HTML in any event).

It started when I wanted to select a couple of lines of material to be color coded in a story, but that wasn't vital, so I ignored it -- after all, why go to such effort for so little added value? Then eight months later (three days ago, in fact), I discovered that “Hồ Chí Minh” and “phở gầu trứng vịt” wouldn't render properly in AO3's default font of Lucida Grande: they should read “Hồ Chí Minh” and “phở gầu trứng vịt”, and I'm a stickler for clear diacritics, so I spent a couple of hours mucking about with CSS in general (useful to ground what I learned afterward on AO3). I use Times New Roman in my own documents and .pdfs, and have no diacritics problems, hence hadn't noticed it on AO3 until now.

**Basic research**

Having [found the AO3 work skins](https://archiveofourown.org/skins?skin_type=WorkSkin), and notably [Homestuck](https://archiveofourown.org/skins/277) (see [this example for its “How to”](https://archiveofourown.org/chapters/2355756?show_comments=true) and [this one to see how that should look](https://archiveofourown.org/works/1159609/chapters/2355671)), I saw how the external CSS method isn't terribly different from raw HTML. The Homestuck work skin uses only Courier (with a default of _[monospace](https://en.wikipedia.org/wiki/Monospaced_font)_ ), which makes it easy to focus solely on font color and size changes and highlighting, or coding errata (for example: although it talks about various characters' individualized fonts, it contains rules for the Caliborn character but not for the Captor character, so if one were to choose the class .captor, then the span of text selected for Captor wouldn't be in a font individualized to them, and so would default to AO3's standard Lucida Grande [or if you right-click to inspect the element: `'Lucida Grande', 'Lucida Sans Unicode', 'GNU Unifont', Verdana, Helvetica, sans-serif;`]). That caught my attention because [MS specifies Courier New for Tiếng Việt](https://support.microsoft.com/en-us/office/choose-text-encoding-when-you-open-and-save-files-60d59c21-88b5-4006-831c-d536d42fd861#bm4) (which is where the diacritic issue came up, after all).

Here's a sample of the _Homestuck_ work skin:

> `#workskin .dad,  
>  #workskin .pipefan413 {  
>  font-size: 14px;  
>  font-weight: bold;  
>  font-family: courier, monospace;  
>  color: #4b4b4b;  
>  }`

The [Undertale](https://archiveofourown.org/skins/74127) work skin turned out to be far more streamlined (lacking multi-functioned classes) and much smoother (with intuitive names) than Homestuck was, and made it so simple to see how to arrange a font-family element. The [Basic Formatting](https://archiveofourown.org/skins/229) work skin was beautiful, mostly just duplicating some HTML and RTF, and adding only font colors.

Here's a sample from _Undertale_ :

> `#workskin .comicsans {  
>  font-family: 'comic sans ms', 'comic sans', 'chalkboard se', 'chalkboard', cursive;  
>  }`

and a sample from _Basic Formatting_ (which has similar simple snippets for indents and spoilers and borders and so forth):

> `#workskin .font-green {  
>  color: green;  
>  }`

So I [tested multiple fonts all at once](https://wordmark.it/) (those already installed, at least) to see which ones would turn “ầ” into “ầ”, “ị” into “ị”, & “ồ” into “ồ” (also [checking some individual fonts not installed](https://www.myfonts.com/search) on my system). While I was at it, I also checked to see if these fonts would fix the problem with “̄S” (combining macron) or “̅S” (combining overline), or if I'd have to keep using the “S̅” that I had found at [fsymbols.com](https://fsymbols.com/generators/overline/) (short answer: I have to keep using fsymbol's overline, though HTML of S&#773; = S̅ works too [obviously]).

That gave me some suitable fonts to satisfy my criteria (in order of descending priority):

  1. Fix the diacritics by placing the grave accent above the circumflex; 
  2. settle for nearly above, if I must;
  3. deal with it being at the leading (left) edge if absolutely necessary. 
  4. Use sans serif fonts if at all possible, in order to minimize contrast with the surrounding text; 
  5. fallback to serif fonts that at least functioned for the diacritics (just in case none of the sans serif fonts were loaded to the reader's device). 



Working all of this out decided the question of the older and mostly irrelevant issue of font colors: as long as I had to make a work skin to fix the diacritics, why not incorporate those too (particularly since I'll likely enough add to it over time)? For example... red, green, and blue text capability (if you look carefully, you'll note that I didn't quite use _Basic Formatting's_ green, having instead chosen to go with `#27b300`). I even tossed in bright yellow and pale yellow highlighting (N.B.: the HTML term is `mark`, but meh) options (though I didn't see myself as likely to use these outside of tutorials, I did end up doing so for the illustration of an admission ticket in an old story]). Once more unto the web, this time for [a color picker](https://www.w3schools.com/colors/colors_picker.asp).

* * *

####  **Results** **Contents ↑**

After all of that, here's my CSS to put into your own skin and work from there, if you'd like -- it pushes 15 fairly popular fonts before giving up, so is likely robust against diacritics failing from dearth of font choice (as long as the reader hasn't disabled creator's style, at any rate):

> `#workskin .diacritics {  
>  font-family: Lucida Console, Arial, Ebrima, Helvetica, Verdana, Segoe UI, Calibri, Candara, Corbel, Microsoft Sans Serif, Tahoma, Times New Roman, Cambria, Constantia, Trebuchet;  
>  }`
> 
> `#workskin .handwriting-printed {  
>  font-family: Segoe Print;  
>  }`
> 
> `#workskin .handwriting-cursive-neat {  
>  font-style: italic;  
>  font-family: Segoe Script;  
>  }`
> 
> `#workskin .handwriting-cursive-scrawl {  
>  font-family: Bradley Hand ITC;  
>  }`
> 
> `#workskin .red {  
>  color: red;  
>  }`
> 
> `#workskin .green {  
>  color: #27b300;  
>  }`
> 
> `#workskin .blue {  
>  color: blue;  
>  }`
> 
> `#workskin .highlight-bright-yellow {  
>  background-color: #ffff0099;  
>  }`
> 
> `#workskin .highlight-pale-yellow {  
>  background-color: #ffffb399;  
>  }`
> 
> `#workskin .highlight-blue {  
>  background-color: blue;  
>  opacity: 0.7;  
>  color: white;  
>  }`

Why is some of my hex code running four pairs? The “99” at the ends of the highlighting color codes is to reduce the opacity so that they don't block text that they overlap on other rows (I went with a higher value so that I didn't have to fiddle with the colors themselves), just like the blue highlight includes “0.7”; for the record, AO3's CSS also accepts RGB and RGBA (i.e.: there are [other color encodings](https://www.w3schools.com/colors/colors_converter.asp) that are not supported on AO3 at this time). You can check the [list of AO3's allowed CSS properties](https://archiveofourown.org/help/skins-creating.html) for more variables once you get the hang of the basics above.

...and that's that for that. Unless you're now scratching your head with materials in hand and no tools with which to apply them... OK, yeah, you can't simply plunk that code into a story's Work Text edit field and watch it go, even if you know how to code CSS for a web page: AO3 uses external sheets (the other two ways are internal in a page's header and inline at any given element within the body of the HTML), so you just have to embrace the suck and use their GUI (I say embrace the suck, but actually I think that it makes this way-the-hell easier to do, and somewhat easier to explain).

* * *

####  **MAKE YOUR WORK SKIN** **Contents ↑**

  1. Copy my CSS snippets from the **Results** subsection, above. 
  2. Go to {My Dashboard ► Skins ► My Work Skins ► [Create Work Skin](https://archiveofourown.org/skins/new?skin_type=WorkSkin)}. 
  3. Paste that copied material into the CSS Edit Field. 
  4. /* Don't bother putting in any notes: AO3 will strip 'em right out. */ 
  5. Fill in all of the other fields of course, just as you would if you were writing a story or chapter. 
  6. Save (edit later, as much as you need/want). 



Want to add something? No problem, toss it in -- here, try these grey highlight (the `line-height` lowers its ceiling, the height raises its `floor`) and double-underscore options:

> `#workskin .highlight-grey {  
>  line-height: 0.3;  
>  height: 1em;  
>  background-color: #d9d9d999;  
>  }`
> 
> `#workskin .double-underscore {  
>  border-bottom: 0.18em double;  
>  }`

  * **N.B.:** Look at these 3 “L”s (normal vs. code surrounds highlight vs. highlight surrounds code) and spot the highlight differences (and it isn't that one set is grey and the other is blue, the extra set being present only for potential viewscreen contrast issues and/or color blindness): 
    * ...l...`...l...``...l...`
    * ...l...`...l...``...l...`
    * The first one (of either row) just highlight's normal size font, but the second and third (of each row) are both highlighted and HTML tagged for coded font. The difference is that the height of the highlighted span is either short to match the shrunken font size (code outside / highlight inside) or tall ( **highlight** outside / _code_ inside). The latter looks awkward to me, but the point is that one's results depend on one's input sequence: which selector (or tag) is applied first (surrounding outside) will determine what the overriding effect will actually be (like a pizza: dough then stuff, not stuff then dough). 



I held off on font size 'til now for reason. You can change font-size in a couple of ways. In a normal web page, you might have used something like HTML (inline CSS) <p style="font-size:30px">for a 30 pixel font</p>, but that's deprecated in HTML 5 _and_ isn't even an option within AO3's HTML GUI anyway _and_ some of the lesser HTML tags don't work right on iOS (more on that in the bonus section). That leaves us two alternatives:

  * Use headings in HTML (the styles of which are controlled by AO3's parent skin, and you can adjust for this, but it's well beyond our scope here: see the bonus round at the end), e.g.: <h1>Heading h1 is pretty big</h1>, <h2>Heading **h2** isn't quite as big</h2>, etc. 
    * (or similarly: <small> and < **big** > [effectively ≈1.2x multiplier, actually only _bumping_ a 16px font into the next text size category of 19.2→19px], which you can nest for n-tuple effects); 
  * Adjust them in a CSS skin (and hope that the reader hasn't disabled creator's style). The explanation for the different ways to change font size is [a bit complicated](https://css-tricks.com/almanac/properties/f/font-size/), so I'll forego that and simply list what they are and how to use them (test and see which one(s) below feel right for _you_ ): 
    * The simplest answer is to use absolute `value` names (e.g.: “small”, “medium”, “large”, etc. -- used like this: `font-size: **xx-large** ;}` [where [xx-large would yield 32px](https://stackoverflow.com/questions/5912528/font-size-translating-to-actual-point-size/5912657#5912657)]), 
      * but for that, you might prefer more control over the actual sizes themselves, so just take normal font size to be 16px normally (which for me is actually 15px, which might be from my browser or monitor or AO3 or other reasons), hence if you wanted to almost double the height of some word, then you might code the CSS as `font-size: **30px** ;}`, 
        * AO3 also permits `mm` (millimeters), `cm` (centimeters), `in` (inches), `pt` ([points](https://en.wikipedia.org/wiki/Point_\(typography\)): 1/72 of an inch, 0.3528 mm), and/or `pc` ([picas](https://en.wikipedia.org/wiki/Pica_\(typography\)): 1/6 of an inch, 4.2(3̅) mm) -- and you can find [conversion charts](https://websemantics.uk/tools/font-size-conversion-pixel-point-em-rem-percent/), but other than points, [these might not be a good idea](https://www.w3.org/Style/Examples/007/units.en.html), 
      * alternatively (because some pixel counts don't change enough to be particularly visible: 15px comes out the same as 16, for example), if you had some specific _multiple_ in mind, then you could code it as `font-size: **1.9r** em;}` and get that word's height to 1.9 times the height of the words around it; 
      * each of these yields the exact result that you aim for, but leaves readers locked into your specific sizes, so that zooming in/out won't help them with visual display (imagine that they don't have their glasses with them or something). 
    * Sometimes you don't have an absolute size in mind for a specific element (or _do_ wish to permit readers' zooming to affect the text's displayed size), and want them to [scale relative to the element](https://cssreference.io/property/font-size/) that they're in, in which case you might instead choose `em`, which is just like `rem` in multiplying a font by some amount, except that `font-size: **1.9e** m;}` will scale with window size (AO3 encourages this approach specifically, due to readers' varied browser and font settings), 
      * though `font-size: **190%** ;}` should(?) come out the same (TL;DR: em on AO3 turned out to be round-down integers only, but **% worked very well for me** ), 
      * and relative `keyword` names (i.e.: `smaller;}` and `larger;}`) are an [OK 3rd choice](https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/): not as much control, but easy to use, the increase being basically around the range of [+1/8 to +1/4](https://manishearth.github.io/images/post/font-size-table.png), 
      * but the remaining possibilities might not be so great: `**1.9ex;}**` (the height of which is relative to the height of the root element's font's lowercase “x” [e.g.: a paragraph font-size being `p { font-size: 2ex;}` would double the size relative to however many pixels were defined in the CSS initially, so had that been `HTML { font-size: 20px;}`, then the resulting doubled height would be 40 pixels for some fonts, but a bit shorter/taller for other fonts]), 
      * or even `**1.9ch** ;}` (this works almost the same way as the `ex` method, but instead of being relative to the height of the root element's lowercase “x”, the `**ch**` is relative to the **width** of the **zero** [which can be wider/same/smaller relative to the letter “ **O** ” from one font to another]). 
    * Then there are size changes that are relative to the viewscreen itself, specifically `font-size: **20vw** ;}` and `font-size: **20vh** ;}`. These will **greatly** affect the font size relative to the _screen itself_ , rather than the rest of the text -- and viewscreens for computers aren't the same size as those for 'phones, so 20v **w** would give a result that's 1/5 of the screen **width** in either case, with the visual flow of text probably(?) rendering differently from one [aspect ratio](https://whatsmyscreenresolution.com/) to another **2** (I've used `vw` only once so far, and that was to adjust a paragraph to resemble [an admission ticket](https://archiveofourown.org/works/24232528/chapters/58437244?style=creator#AcmeTicket) [I'm disinclined to use a public domain image as a background or sketch my own, and I don't know if AO3's CSS even supports SVG to code for a fancier border], so I'm not very experienced or well-practiced with `vw`). 

> `#workskin .ticket {  
>  width: 20vw;  
>  text-align: center;  
>  background: #ffffb399;  
>  min-width: 15em;  
>  }`

    * I gave in to my OCD and tested them out in a skin to see their effects (except for vw/vh, for reasons). For whatever it's worth, here are _my_ results (taking the unaffected 100%-zoom 12px height lowercase-"h" as my standard, so that 190% = 22.8px [rounded to nearest integer would give 23px] and 200% = 24px), though I resisted checking multiple zooms and nested elements-within-elements; **your** mileage might vary: 
      * h1, h2, h3, and big = remained 12px tall... **FAIL:** no change (I didn't expect these to work in CSS); 
      * xx-large = 25px [x-large only 19px] -- **OP CK GOOD** (these working surprised me); 
      * 30px in CSS gave 22px(?!?) as a result... **EPIC FAIL:** can't rely on an "exact" measurement; 
      * 22pt = 21px, and 22.5pt & 23pt both gave 22px... **WORKAROUND:** these should've been 30px(±0.7), but functional _enough_ if one assumes pt≈px (30pt = 29px); 
      * 1.9rem = 22px, 2rem = 23px -- **OP CK GOOD** ; 
      * **1em & 1.9em = 11px (not 12px: these _shrank_ my sample by 1px), 2em = 22px -- OP CK GOOD;**
      * **190% = 21px, not 22.8px→23px (N.B.: but finer control than em...) -- OP CK GOOD;**
      * larger = 13px (1px larger), not 14.7px(=15px)-16px... **FAIL:** no significant change (didn't expect it to work at all, so this is something anyway); 
      * 1.9ex = 11px, 2ex = 12px, 3ex = 17px, and 4ex = 23px... **EPIC FAIL:** with a lowercase "x" height of 8px, these should've been ~15.2px, 16px, 24px, & 32px, respectively (i.e.: results were ~71-75% of expected values); 
      * 1.9ch = 14px (2px larger), 2ch = 15 (3px larger), 3ch = 22px, and 4ch = 29px... **EPIC FAIL:** with the width of a zero "0" being 9px, these should've been ~17.1px, 18px, 27px, & 36px, respectively (i.e.: results were ~81-83% of expected values). 
    * In every case, it might be a good idea to [check their browser-compatibilities](https://developer.mozilla.org/en-US/docs/Web/CSS/font-size#browser_compatibility), if only to at least cover the major bases. 
    * **N.B.:** I found that the **em** approach works a little differently for images, or at least on AO3 using straight HTML (not in a CSS skin, where one might expect em to be used): in the img tag, I wrote width="40em" directly within the HTML GUI, and it sorta worked.  
Based on how em _should_ work, I had initially scaled an image's width to 2em (which at 15px height per em should give 30px of width for this image), on the assumption that this would yield a width of approximately 2 text-heights (I'm trying to control image height directly, but seem constrained to controlling it by adjusting the width); instead, the result was perhaps 2 pixels of height -- but it _did_ work (albeit not as intended). That said, I found eventually that 40em worked optimally for my purposes; what should have resulted in an image width of 40 text-heights came out as ~2 text-row heights.  
I take this to mean that to some extent "em" is read **for images** as the object's pixels (that is: a row of text isn't just the height of a font, but includes some padding above and below: highlighting [with class=] some normal text at 100% zoom, a screencap dropped into MS Paint showed the letter "h" to be 12px, but the height of the row's highlighting to be 24px; this is exactly in keeping with my earlier need to adjust highlight opacity, since each text-row's span height turns out to be **20px** non-overlapping + 2px overlapping padding below [merely selecting a few rows of text via cursor gave seemingly-less relevant results of 14+5]).  
For the curious: see the **gilded capital-O image** (basically a medieval illuminated text image) that opens the first paragraph of “ **[Zelda Invictus](https://archiveofourown.org/works/24228373/chapters/58374028)** ” (the chapter note of which explains a bit more detail of the image size tests). 

After the rigmarole of which font size methods work in one fashion vs. another (if you clicked to here by the TOC instead of reading all the way through: **try to use em, not px** ), here's an example of how to skin them (pick any **one** per snippet/ not some / not all): **Contents ↑**

> `#workskin .courier {  
>  font-family: courier, monospace;  
>  }`
> 
> `#workskin .courier-30 {  
>  font-size: _xx-large / ~~30px~~ / 30pt (maybe others) / 1.9rem / **2em** / **190%** / ~~larger~~ / ~~1.9ex~~ / ~~1.9ch~~..._;  
>  font-family: courier, monospace;  
>  }`




And... badda-bing, you're G2G! Except that you might not know how to actually _apply_ any of this; there's a decent chance that you know some common HTML tags such as `<b>`, `<u>`, and `<i>` (and speaking of italics, by now you might have enough to work with to consider changing font angles through the work skin using `font-style: oblique 10deg;}` or some other angle [a back-sloped angle being in negative degrees, [which is browser-dependent](https://developer.mozilla.org/en-US/docs/Web/CSS/font-style#browser_compatibility) at the time of this writing]; I gave it only a quick try, no dice)... but how do you **use CSS selectors** in your story?

* * *

####  **Using CSS selectors in your chapters' HTML:** **Contents ↑**

If you need to learn how to tag paragraphs or spans with an #id selector or a .class selector, then I **_strongly_** suggest [Khan Academy](https://www.khanacademy.org/computing/computer-programming/html-css) (or search there for another CSS course), and maybe a brief stop at [W3Schools](https://www.w3schools.com/html/html_classes.asp) and [CSS-Tricks](https://css-tricks.com/the-difference-between-id-and-class/), but here's a quick and dirty demo. If you do have some clue, but not much, then [consider this AO3 FAQ](https://archiveofourown.org/faq/tutorial-creating-a-work-skin) instead (or as well), and possibly [AO3's allowed HTML FAQ](https://archiveofourown.org/help/html-help.html). If you're already a wiz, you might not be reading this -- granted -- but you might wish to work on some [advanced special effects](https://archiveofourown.org/series/458134).

First: check my code. Notice how the first one is called “ **.** diacritics”? Ignore the word _diacritics_ , that's just a convenient choice of word for me (you might prefer to name it _accent-marks_ or _semantic_marks_ or _IshKabibble_ : don't worry [anyone get this joke?], that part is entirely up to you as long as you **don't start the name with a number** , so .answer42 is OK but .42answer will stay in the CSS skin but the HTML parser will strip it right back out [just don't leave a space in the name, and avoid most special symbols; I prefer the underscore conceptually, but the dash makes it so that I can double click just one word and replace it, rather than click-and-drag across the characters that I need to change in the name]). Instead notice how that selector begins with a “ **.** ” period; that makes it a **class selector** , and one of those can be applied to **as many different spots as you want** , like a **generic bar code** (a can of soup at the store will have the same bar code as any other can of the same brand and type).

Sometimes you might want to identify a unique section for some reason; I had no need for that, but had I, then I would have written “ **#** diacritics” instead. Notice how this one starts with a “ **#** ” pound sign instead; that makes it an **ID selector** , and they're like a **serial number: one use only** and that's it.

To make the word “red” turn red, I'd simply tag that word (or set of words, or whatever) as follows:

> <span class="red">red</span>

Maybe the word “`span`” (a term for distance) isn't familiar to you. Let's try something more familiar: raw HTML. Is this paragraph example a little better?

> <p align="justify" class="red">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

We can even use multiple class selectors on the same element. For example, if I wanted to mix `<span class="diacritics">ầ</span>` with `<span class="red">ầ</span>` in order to achieve ầ, then I could simply write it as **3**

> <span class="diacritics red">ầ</span>

Cool. What if you have 20 paragraphs that you want in red, then 10 in red and italic (or a different font size, or whatever), then 20 in just italic? Well, aside from writing a new CSS snippet that turns text into italic form and combining the class selectors in your HTML (or writing a CSS snippet that does both, if you're liable to use the combination often), you might have a lot of copy-and-paste on your hands -- or you could just start with a `<div>` tag right before the beginning of that first paragraph, go to the end of those first 20 paragraphs, toss in a `</div>` tag, etc., and add the appropriate class selector(s), of course.

> <div class="red">  
>  <p>The first paragraph that you want to be re-formatted.</p>  
>  <p>A zillion more paragraphs in the middle.</p>  
>  <p>The last paragraph of _this_ set that you want formatted in one swell foop.</p>  
>  </div>

Rinse and repeat for changing fonts or highlighting, etc.. Don't forget that you _can_ write CSS selectors to perform the same functions as HTML tags ( **< b>**, <u>, _< i>_, etc. -- deprecated these days in favor of things like `<em>`, but I'm old school [muscle memory], and the AO3 parser will automatically replace them “for” you if you use the older forms); I haven't, but you never know when you might want to change _all_ of one to _all_ of another (or some portion of them, on a case-by-case basis). Now consider the reduced time factors involved with one method vs. another:

  * Scrolling through the entire document and manually hitting the button-on for one and button-off for the other (or even hitting CTRL- _whichever_ for each) in every single instance in RTF vs.
  * hitting CTRL-F / ⌘-F / grep to jump to each relevant tag in your HTML, then hitting CTRL-V vs.
  * swapping between AO3 and your offline copy for find-and-replace-all vs.
  * simply going to your work skin and changing the single line of that class selector's code (e.g.: “`.SecretSquirrel'sAddress { color: red`” → “`.SecretSquirrel'sAddress { color: blue`”).



That might explain some use for class selectors, but why bother with an id selector? Well, what if you don't want to sift through a hundred chapters or load them all as a single page (and CTRL-F / ⌘-F / grep) in order to find and change the properties of a specific comment in a thread or a crucial NSN (National Stock Number) somewhere in your document? Yeah, sometimes a unique identifier can be useful.

 _Before you go, please, lemme ask just one last question there, Lieutenant Colombo, if I could have a moment of your time -- please:_ “`#workskin`” begins with “ **#** ”, so it's an id selector calling the work skin in the first place, so is nesting id="SomeUniqueName" even possible here? Let's try it out.

> `#workskin #purple {  
>  color: purple;  
>  }`

If THIS TEXT RIGHT HERE is purple, then yes, it works. Oh look, it's not purple (and I tried colorizing the span using both _id=..._ as one would here and _class=..._ just in case). We might have to simply use class selectors with unique names for such cases as would normally have had id selectors (unless I ferret out some way to make id selectors function [in the CSS] within AO3 work skins [N.B.: id selectors _do_ work on AO3 mind you, as in the case of this work's header-note/footnote links]).

**Provisos**

  * Just like you can have a zillion fics, whether you have skins or not, you can just as easily have have a zillion skins, whether you have any fics or not. You can always edit the skin's effects, or change which skin applies to a fic. You can use a work skin on as many fics at once as you wish -- but any given fic **can't have more than one skin at a time applied to it**. 
  * This is just my own take on it, but if AO3 permits you to do something with HTML, then go that route instead of relying on CSS solely -- if the reader disables creators style, then this will minimize that impact on their reading experience. 
    * Aside from layout and style differences if the HTML weren't to parallel the CSS as closely as possible, consider a simple image: one could insert `#workskin .pictures { max-width: 100%; height: auto;}` into one's skin to automatically scale a map (damned good back-up in case you forget to scale it when you link the image) and hit the image's HTML with something like <img **class="pictures"** src="URL.jpg" alt="A few descriptive words." />, but without <img src="URL.jpg" alt="A few descriptive words." **width="100%" height="auto"** /> also in the HTML, that map image could still end up far too small/large if the reader were to disable creator's style. 
  * FIFO: _First-in-first-out_ **doesn't** apply here. AO3's parser will fix mistakes, but it's still good practice to close your most recent tag or selector before closing less-recent ones. For example, you could write `< **span** class="blue">< ** _code_** >.Fo { ob: ar;}< **/span** >< ** _/code_** >` and it should correct it to `< **span** class="blue">< ** _code_** >.Fo { ob: ar;}< ** _/code_** >< **/span** >` for you, but sometimes it will glitch, and you might even confuse it so badly that it can't properly correct it. (This is otherwise an important practice if you were to write a regular webpage somewhere out there: even if it were to come out OK for you, an older browser might not be able to sort out your mistake.) 
    * And here's my code for circling words (a modified version of [a StackOverflow answer](https://stackoverflow.com/a/8965594)); I'm still trying to work out how to present a circling that doesn't rely on the border itself (since you can't shrink the border to within the height of the contents without SVG, and I'm still trying to work out if that's even supported on AO3, perhaps a varying gradient could be applied to `ch`): **Contents ↑**

> `
> 
> #workskin .circle-red {  
>  border: 0.14em solid white;  
>  border-radius: 0.3em;  
>  border-color: red;  
>  padding: 0.05em 0.05em 0.05em 0.05em;  
>  text-align: center;  
>  margin: 0.15em;  
>  }
> 
> #workskin .circle-green {  
>  border: 0.14em solid white;  
>  border-radius: 0.3em;  
>  border-color: green;  
>  padding: 0.05em 0.05em 0.05em 0.05em;  
>  text-align: center;  
>  margin: 0.15em;  
>  }
> 
> #workskin .circle-blue {  
>  border: 0.14em solid white;  
>  border-radius: 0.3em;  
>  border-color: blue;  
>  padding: 0.05em 0.05em 0.05em 0.05em;  
>  text-align: center;  
>  margin: 0.15em;  
>  }
> 
> `

  * AO3 does accept the CSS `display: inline-block`, but keep in mind that whatever it affects won't be able to line break (it will be non-wrapping -- _ask me how I know_ ).
  * Also: do keep in mind that even if the reader hasn't disabled creator's style, even though HTML formatting should be OK in a downloaded version, nonetheless the **[CSS formatting still won't appear in downloads](https://archiveofourown.org/admin_posts/119) (.pdf, .epub, or .mobi files)**
    * nor will the vertical bar along the left side of blockquotes,
    * nor the _overspill_ of fonts listed in my code after Microsoft Sans Serif (`Tahoma, Times New Roman, Cambria, Constantia, Trebuchet;`),
    * nor any words copied from <https://yaytext.com/bold-italic/> (as in the case of those at the bottom of this tutorial's summary, the {𝑫𝒐𝒏'𝒕 𝒇𝒐𝒓𝒈𝒆𝒕 𝒕𝒐 𝑳𝒊𝒌𝒆, 𝑺𝒉𝒂𝒓𝒆, 𝒂𝒏𝒅 𝑺𝒖𝒃𝒔𝒄𝒓𝒊𝒃𝒆! ❤️} text doesn't show there [nor here] when viewed in a download [though that text is visibly different in the summary even in the search lists, implying that the external font pasted in is supported by AO3's overall CSS, therefore CSS effects in a summary _can_ be caused to be visible in search-views to an extent] -- though the S̅ from <https://fsymbols.com/generators/overline/> will function even in a download, implying that it's maybe an actual font instead of CSS of style="text-decoration:overline" [though inspecting that page showed their “S̅” to be `font-family Arial Unicode MS, 'lucida grande', tahoma, verdana, arial, sans-serif;`]; 
      * I assume that it ultimately comes down to whether your own device has any given font available, rather than AO3 embedding-or-not of fonts into the downloads),
      * contradictorily, I tried the other download options and found that the words from yaytext.com (inspect element revealed their bold-italic-serif font-family to be `TimesNewRoman, Times New Roman, Times, Baskerville, Georgia, serif;`) remained present in the HTML, as did those missing fonts listed in the snippet of my CSS, and the code snippets are in the original code-looking font or similar enough, but I don't have any suitable programs to check the .azw3, .epub, or .mobi versions (and I'm not going to get anything just for this); 
        * N.B.: I've mentioned “inspect element” a few times now, but if you've no idea what that means, there are a few ways to open the developer tools: 
          * right-click ► inspect [element] ► styles
          * F12
          * CTRL-SHIFT-I
          * CTRL-SHIFT-C
          * ⌘-⌥-I
          * ⌘-⌥-J
          * ⌘-SHIFT-C
          * or several ways on [different browser menus](https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_are_browser_developer_tools)
      * and the diacritics in the .pdf don't have their CSS and so are rendered a little oddly in whichever font the .pdf chose (I'm not going to even try to fix that).

**Testing**

If you're feeling really froggy, you might even run the page through a few browser emulators to see how it presumably looks through them. I don't plan to, but you can can find them via Google or DuckDuckGo or wherever. How well they might work is a dice roll. By way of example: I know how my stuff looks through several browsers, but only when running in a Win 10 environment; I went through Chrome and tried <http://classic.oldweb.today/> for shits and giggles, where I ran an emulation of Firefox (which I have, and so know how my stuff looks in Firefox on my system) and they set that up as if in Linux (which I'm not running, though Mint looks tempting), and their result wasn't the same, but I don't know if I should have expected it to be since I'm not dual-booted. This idea becomes increasingly unappealing if one considers that apparently most readers access AO3 via the 'phones, and there are [a _lot_ of variables there](https://dev.opera.com/articles/opera-mobile-emulator/) (worse, if you tried to cover [everything possible](https://developers.whatismybrowser.com/useragents/explore/)).

* * *

####  **😺 BONUS ROUND: you've been patient, so here's your cookie! 😺** **Contents ↑**

Before we get to the bit that intrigues me, I'll mention one of the more recent bits that you might have run into of late and which certainly showpieces some flashy potential. I'm assuming that you've probably dug through available resources on [work skins](https://archiveofourown.org/works/search?utf8=%E2%9C%93&work_search%5Bquery%5D=work+skin), [CSS](https://archiveofourown.org/works/search?utf8=%E2%9C%93&work_search%5Bquery%5D=css), and semantically similar variations, but bear with me for a moment here. (By the way: I didn't use any of the code from “[All the emoji](https://archiveofourown.org/works/6580324/chapters/15055576)” in order to emplace the emoji in this tutorial, I just copied them from Facebook and pasted them right in without thinking; I got lucky, but this also means that maybe copying from Facebook is a workaround, or that AO3's database now supports emoji.)

As a late edit, this paragraph is probably better fit with the theme of skin873 (farther down), but I'm putting it here because of its intermediate level material (way past this 101 tutorial). Skin873 is more for the advanced students (which I most certainly am **not** ).

    * For those who wish to know just what they can do with their outside CSS skills, or wish to work at a higher level than just fonts, please see AO3's “[full list of supported CSS properties](https://archiveofourown.org/help/skins-creating.html)”; 
    * for those who'd like to really stretch what they can do with AO3, but need more intel on what's where here, please see dustnik's “[AO3 CSS Selector Ids and Classes](https://archiveofourown.org/works/24906427)”. 

I mentioned a couple of fics linked in this tutorial's Summary section. [How to Override the Archive's Automated Chapter Headers](https://archiveofourown.org/works/16737931/chapters/39262852) is more tutorially dry-seeming (but beautifully concise) and less dazzling than Bleed Gold (I call it that due to the .png header [even though it's green onhover], but the title is actually the slightly less catchy “CSS in Testing”), and one can see the impact far more clearly in Bleed Gold -- but Bleed Gold presents a surprising layer of subtlety in its End Notes. Although these two examples present far more flexibility than I'm liable to make use of, those of you who seek to present eye-catching effects (webpage-like, in the case of Bleed Gold) in AO3 could benefit from it, and there are others:

    * [comic book thought bubbles](https://archiveofourown.org/works/4384112) (disable that tutorial's style to see their CSS that they plaintexted into the body of their tutorial), 
    * [sticky notes](https://teekettle.tumblr.com/post/121690800779/so-after-i-made-my-last-workskin-insanewordcount), 
    * [OnHover](https://archiveofourown.org/works/10957056?style=creator) (which can have trouble rendering certain characters without using CSS (ISO), 
      * though you could simply eschew the CSS in favor of <acronym title="Here you'd enter the words that you want the hover-box to show">using some inline HTML for a little OnHover box</acronym> from CodenameCarrot's [guide to limited HTML](https://archiveofourown.org/works/5191202/chapters/11961779) [ **caution:** this latter OnHover box might fail on mobile devices]), 
    * [Screenplays](https://archiveofourown.org/works/17663495/chapters/41658683) (though [this one](https://trilies.tumblr.com/post/638311425980448768) might be simpler), 
    * black backgrounds -- I've seen at least one, but can't find it now, so here's InfinitysWraith's example from [r/AO3](https://www.reddit.com/r/AO3/comments/kamz06/is_it_possible_to_make_a_work_skin_with_a_black/), who notes that one can use the nested id pair “#workskin #chapter-1” (etc.) for per-chapter effects: 

> `#workskin {  
>  background: black;  
>  color: white;  
>  }`

    * Choose Your Own Adventure (La_Temperanza [covered these beautifully](https://archiveofourown.org/works/11514573), and MohnblumenKind hit them succinctly [in chapter 6](https://archiveofourown.org/works/15685086/chapters/39753822?style=disable)), 
    * [iPhone screenshots](https://archiveofourown.org/works/6434845/chapters/14729722) (again: disable that tutorial's style to see their CSS that they plaintexted into the body of their tutorial), 
    * Even [layouts for podfics](https://archiveofourown.org/chapters/32948232?show_comments=true#comments) for readers' convenience, 
    * or ElectricAlice's “[How to make a fanfic header Ao3 Style inside your own fanfic](https://archiveofourown.org/works/26662207)”, which might be a good launching point to modify for those who need more note-space than the header-notes and footnotes permit, 
    * though of course, there are 
      * **[site skin snippets that a reader can likewise use](https://www.reddit.com/r/AO3/comments/lnrt14/i_i_was_just_trying_to_see_if_a_tag_i_used_had/go3awpd)**
      * to **[block an author](https://ao3commentoftheday.tumblr.com/post/643031282990891008/i-posted-this-in-text-form-yesterday-and-got-a)**
      * or **[shorten walls of tags](https://archiveofourown.org/skins/3756)**
      * / **[walls of 'ships](https://insanitysilver.tumblr.com/post/643767335759626240/ao3-userscripts-you)** , 
      * and there are **[other snippets with different approaches](https://resonance-and-d.tumblr.com/post/642507957857386496/custom-tag-limits-on-ao3)** to do this, 
      * or just **[using browser extensions](https://ao3commentoftheday.tumblr.com/post/634548736342769664/ao3-blocking)** , 
    * etc.. 

When actually viewing the fic's page itself, the Bleed Gold effects on its summary contents are present when set to [Show Creator's Style](https://archiveofourown.org/works/25174384/chapters/61560142), and absent when set to [Hide Creator's Style](https://archiveofourown.org/works/25174384/chapters/61560142?style=disable). The fun trick (that subtle twist that I mentioned initially) comes when you _click_ “[(See the end of the chapter for more notes.)](https://archiveofourown.org/works/25174384/chapters/61007614#chapter_5_endnotes)” [sic]: it goes to an entirely different chapter (cf. exact wording of “note” link vs. standard, and URL of [Bleed Gold](https://archiveofourown.org/works/25174384/chapters/61560142%22%20rel=%22nofollow%22) vs. URL of its notes): bluntly, they're actually not that same chapter's end notes themselves at the bottom of the page (though the formal function is pretty much exactly that), but rather a whole new chapter with a somewhat different summary.

Addendum: for those who would prefer some layer of security against plagiarists copying their material, I give you the following code from [0KKULTiC on Twitter](https://twitter.com/0KKULTiC/status/1228822106709860353) (who states that it doesn't work on iOS Safari) -- they provided a [linked example](https://archiveofourown.org/works/20843018/chapters/49547579) that I was still able to copy and paste from (without first disabling creator's style), but the principle is still worth mentioning:

> `#workskin p {  
>  -webkit-user-select: none;  
>  -moz-user-select: none;  
>  -ms-user-select: none;  
>  user-select: none;  
>  }`

Now for the bits that I haven't seen mentioned anywhere else.

I looked under the hood. Found inherited font-family `'Lucida Grande', 'Lucida Sans Unicode', Verdana, Helvetica, sans-serif`. Couldn't shake a feeling that something was “off”, especially after seeing fonts of .pdf and .html downloads from fics with no CSS in the first place.

Tried identifying fonts through cropped shots of AO3 online vs. downloaded forms using  
https://www.myfonts.com/WhatTheFont/result

Right-clicked to inspect element, noticed `div.userstuff.module` (cf. user agent stylesheet in the flashy pages, e.g.: [Sliding Doors](https://archiveofourown.org/works/149319?style=disable) [the body of which explicitly includes `/* CSS notes */`, but was written in 2011, hence prior to the note-scrubbing that occurs nowadays {which I presume was part of the 2016 Archive 2.0 sweep}, therefore its CSS likely no longer includes them])  
<link rel="stylesheet" type="text/css" media="screen" href="/stylesheets/skins/skin_873_archive_2_0/1_site_screen_.css"/>

Long story short: the trail led to [**skins/873**](https://archiveofourown.org/skins/873) \-- not itself a skin, but a parent page (either it simply lists available skins that happen to be linked, or site skins are chained to call 873 itself which in turn calls from any skin pages chained into it). There are 32 skins listed there right now, so I'll drop only a couple of small sample snippets. It turns out that it's [not a secret though](https://archiveofourown.org/faq/tutorial-creating-a-work-skin?language_id=en#wksknintro), just not something that you're liable to think about if you were to run into it early on. Work out which ones are used where, and you might have an easier time doing your own site skins (and probably come out with a few nuggets for work skins and CSS in general [those of you with a broader skill-set might prefer OTW's source on [GitHub](https://github.com/otwcode/otwarchive)]).

https://archiveofourown.org/skins/842  
Archive 2.0: (1) core skin by AO3

> `body, .toggled form, .dynamic form, .secondary, .dropdown {  
>  background: #fff;  
>  color: #2a2a2a;  
>  font: 100%/1.125 'Lucida Grande', 'Lucida Sans Unicode', 'GNU Unifont', Verdana, Helvetica, sans-serif;  
>  margin: 0;  
>  padding: 0;  
>  }`

https://archiveofourown.org/skins/843  
Archive 2.0: (2) elements skin by AO3  
From what I can see, it seems that at least some of the raw HTML inline-seeming elements (to wit: “`<code>`”, if nothing else) that we code in our writing aren't actually running inline, but are apparently instead simply acting as class selectors and calling the functions defined in the relevant AO3 stylesheets (depending on whether the element is in the summary/notes, body, etc.).

> `body {  
>  font: 100%/1.125 'Lucida Grande', 'Lucida Sans Unicode', 'GNU Unifont', Verdana, Helvetica, sans-serif;  
>  }`
> 
> `h1, h2, h3, h4, h5, h6, .heading {  
>  font-family: Georgia, serif;  
>  font-weight: 400;  
>  }`
> 
> `blockquote, pre {  
>  font: 1em 'Lucida Grande', 'Lucida Sans Unicode', Verdana, Helvetica, sans-serif;  
>  margin: 0.643em;  
>  }`
> 
> `kbd, tt, code, var, pre, samp {`  
>  ` font: normal 0.857em 'Monaco', 'Consolas', Courier, monospace;  
>  margin: auto;  
>  }`

Well, you get the idea. The snippets that I showed here are only relevant to fonts (since I'm focused on simple typesetting and basic layout, mostly), but the original sheets contain a lot more formatting code than just this stuff (takeaway point if you're looking for bells and whistles). Have fun! 😉 (I'm going to go back to trying to get my charmap to gen “␢” from U+2422 or ALT+09250.)

**O ~~~ O**




**Author's Note:**

>  **1** Clearly, CSS effects can function in footnotes, too.
> 
> **2** There's another page with [an extremely similar URL](https://whatismyresolution.com/%22) that has some good aspect ratio info in the pages that it links to.
> 
> **3** Although each chapter's main body of text has plenty of character count to play with, so that you needn't combine CSS selectors, and footnotes have plenty of space for most people, sometimes you have a huge note (or set of notes). With a 5K char limit in each note section, this means that the character count for anchors takes up space already (if you put anchors into the footer in order to link the text to the note), and return links add to that load (if you have enough space to put these in so that readers can go right back to where they'd left off in the text).
> 
>  **Standard anchor & href** = 40+52=92 characters (or 85 if not bold) minimum:
>
>> <a name="1" rel="nofollow" id="1"></a>1 ←40 char. (incl. the trailing space) + 52 char. (incl. the leading space)→ <b><a href="#a1" title="1" rel="nofollow">↑</a></b>  
> 
> 
>   
> To cut this down, you can remove “title=...” (which means no hover text, but frees up 8 char.s each time, plus the title lengths, plus the trailing space of each, totaling 10 or more), and combine your footers' HTML tags thus:
> 
>  **Combined anchor + href** = 58 characters (or 51 if not bold) minimum:
>
>> <b><a href="#a1" name="1" rel="nofollow" id="1">1</a></b> ←58 char. (incl. the trailing space).  
> 
> 
>   
> That's only 34 characters of savings per linked footnote, but they add up fast (almost the difference of having only two links vs. managing to squeeze in a third).
> 
> Keep the “name=...”, even though you have an “id=...” in there, or else the click won't go anywhere. Don't bother removing the “rel=...” or the “id=...”, because AO3's parser will insert them automatically, and these **do** still count as characters, so you'll want to keep as accurate an eye on that count as you can get (the notes' char. count is a bit “iffy”, and so I find that how many I have left is a problem at around 30 characters [sometimes 60] rather than 0, and that's _even without_ any links in the notes). Why _both_ anchors? Probably to cover all bases: older user agents don't support id anchors, and name anchors are deprecated in HTML 5.
> 
> Bottom line:
> 
>   * Use something like this in the chapter: <b><sup><a href="# _4_ " name=" **a4** " rel="nofollow" id=" **a4** ">4</a></sup></b>
>   * **but** something like _this_ in the footnote: <b><a href="# **a4** " name=" _4_ " rel="nofollow" id=" _4_ ">4</a></b>
>   * **N.B.:** this is for the footnote and text anchor points to link back and forth. If the chapter text doesn't link to the footnote, then the footnote won't need the name= or id= portions. 
> 

> 
> * * *
> 
> If you're really pressed for space, but still have a little to play with, then I'd suggest keeping the footer's “href=...” return link material (so that readers can get back to the right anchor in the reading material) and ditching the footnote anchor's “name=...” & “id=...” (since readers can easily scroll down to the bottom of the page without a link to it). This would cut out a further 9+7=16 characters, resulting in a 42 char. (incl. a leading or trailing space) bare minimum (or 35, if not bold), with negligible impact on functionality; if you were to go this route, then you would also **no longer need to add a character to differentiate between the text's anchor “a1” and the note's anchor “1”** and so could shave off one more char. each time, giving you 41/34 char.s.
> 
>  **Only href** = 41 characters (or 34 if not bold) bare minimum:
>
>> <b><a href="#1" rel="nofollow">1</a></b> ←41 char. (incl. the trailing space).  
> 
> 
>   
> In extremis, you could just link the first word of each note (rather than enumerating them _plus the number's trailing space_ before the text) and so remove a last two char.s each time for a final tally of 39/32, but this really risks making the notes a bit difficult to find if there are many small ones (and the return-linked word would look like an external-URL link).
> 
>  **Note's first word is href** = 39 characters (or 32 if not bold) bare minimum:
>
>> <b><a href="#1" rel="nofollow">←31 char. + 8 char.→</a></b> (no _extra_ spaces needed)  
> 
> 
>   
> 


End file.
